INDs (Intermediate network devices), such as gateways or network access devices, including Internet gateways, have evolved in complexity in recent years. Their usage is commonplace, they may integrate, for example, high-speed gateway anti-virus, anti spyware, intrusion prevention, content filtering, stateful firewall, IPSec VPN (Internet Protocol Security, Virtual Private Network) and more.
As more features are provided and used so there can grow an increasing reliance on the benefits thereof and a correspondingly growing need to manage and limit the consequences of extraordinary events including signal borne threats and/or device degradations or even complete failures. Various capabilities for threat management, including UTM (unified threat management) exist in previously developed solutions however improvements in reliability, graceful degradation and flexible response modes are needed.
In a communication network, if a connecting device (such as switch/router/UTM (Unified Threat Management) appliances or firewall) fails due to hardware or software malfunction, it could result in terminating the connection between the ingress and egress ports. For an inline device such a malfunction would then stop the flow of the data across the device resulting in network down time.
There are old methods of bypassing the devices manually, or always asserting bypass, on system failures. Such “bypass-always” devices allow a complete bypass always (on failure) and may have no mechanism to inhibit this bypass based on system configuration and application. These implementations may not allow the choice of selecting whether to bypass or not to bypass based on the system application either at all, or not in a sufficiently adequate manner.
Utilizing a “manual-bypass” method may result in experiencing network downtime and/or may require an IT (Information Technology) person to find a failing device and then bypass it manually. This may be very time consuming and costly.
Utilizing an “automatically bypass-always” method for UTM appliances may result in experiencing undesired network connectivity in cases where system applications do not want to allow data flow-through whenever a system fails. Such a case is commonplace in security and firewall applications.
FIG. 1 is an illustration of part of a network configuration. Internet (internetwork) 101 is connected by some form of telecommunications link 102 to a network access device 110. The network access device 110 may operate as a gateway to provide internetwork (external network and/or Internet) access to devices (not shown) that may be connected to a LAN 120 (local area network). Typically, the network access device 110 may perform gateway algorithms to enable it to operate as a firewall, router, virus detector, and/or provide numerous other services.
FIG. 2 is an illustration of part of a network configuration, such as that of FIG. 1 under a possible failure condition that may be viewed as a “fail closed” condition. Failures can occur in many ways, often not entirely capable of being anticipated, like the destruction of an electronic circuit, loss of electrical power, or undesired software behavior.
In the system of FIG. 2, failure has resulted in a “No Connection” condition between the LAN 120 and Internet 101. This type of failure is commonly termed “fail closed” as no data traffic is allowed to flow through the network access device 110 anymore. Unless a fallback network access device (not shown) exists and offers an alternate route for such data flow, service is effectively disrupted pending remedial action by personnel and/or equipment repair or replacement etc.
FIG. 3 is an illustration of part of a network configuration, such as that of FIG. 1 under a possible alternative failure condition that may be viewed as a “fail open” condition. In this case the network access device 110 has failed in a way network access device 110 no longer provides enhanced services and data passes freely, without filtering, virus checking or whatever services network access device 110 might be intended to provide when fully operational. In some embodiments network access device 110 may behave in this failure mode as an IEEE-802.3 “hub” device. This type of failure is commonly termed a “fail opened” (or “fail open”) failure suggesting that the interconnection is opened up for any and all data flow to pass unimpeded. Unimpeded data flow can have various consequences, for example there may be a failure to block undesirable software viruses and data flow that should be confined to the LAN is allowed to leak upstream thus providing needless and unproductive data flow loading to upstream network devices.
It is a limitation, commonly found in previously developed solutions that a choice between the failure modes of FIG. 2 and FIG. 3, where available at all, must be made long in advance, such as when the network access device is placed into service rather than in a programmable manner, responsive to varying system configuration.
Additionally, in previously developed solutions, many devices are not capable of “fail open” behavior when unpowered such as when failure is due to power supply malfunction. This can result in inconsistent behavior improperly responsive to the (sometimes unpredictable) precise nature of each failure.